Such a telecommunications network groups together a plurality of pieces of equipment, of links, and of functions dedicated to transporting data issued by terminals connected to the network. In particular, transport functions may be implemented by activating routing and transmission protocols. Below, a telecommunications network administered by an operator is also referred to as a domain.
IP networks include devices that are known as “routers” and that serve to route packets of data to their destinations on the basis of a destination address displayed by each packet received by the router. To do this, the router uses a “routing table” containing “routes”, each route being constituted by a prefix (common to a plurality of addresses) or by a complete address (specific route). More precisely, the router determines how it is to route the packet by searching for the longest series of bits that is common to the destination address and to a route mentioned in the routing table.
An Internet service provider (ISP) deploys a dedicated architecture to enable the users of terminals to be reachable. Access to the IP connectivity service is managed by the ISP who relies on the telecommunications network of an operator to route data packets issued by terminals to their final destinations. Under certain circumstances, said service provider is also the operator of the telecommunications network.
Such an ISP allocates an IP address, generally a public address, to a home gateway placed between a home network and the public network, i.e. the operator's IP domain. The home gateway generally allocates private IP addresses to the terminals in its home network.
Below, the term “home gateway” is used to designate any equipment for providing interconnection between a private domain and a domain operated by a service provider, where the private domain may equally well be a home network or a business network. Furthermore, the domain operated by an ISP is also referred to by the term “public network”.
Placed as a communications bridge between a terminal of its private domain and the operator's IP domain, the home gateway includes, in known manner, a table in which it associates the private IP address of the terminal in the private domain with a public IP address of the gateway in the public domain. Often, the number of public IP addresses usable by the gateway is much smaller than the number of private IP addresses that are potentially usable by the terminals in the private domain. In a residential context, the gateway almost always has only a single public address available thereto.
More precisely, when converting the header of a data packet leaving the private domain (a private address and a private port are replaced by a public address and a public port), the gateway selects an available public port. Thereafter, for an incoming packet going to said public address and said public port, the gateway knows how to convert the header into a private address and a private port (before relaying the packet to the terminal in question), since it has retained in a table the match between the private address and private port pair with the public address and public port pair. Usage of the public address is thus shared between the terminals of the private domain.
This table is known to the person skilled in the art as the “natting table”, which term is derived from the acronym NAT standing for “network address translator”. In order to be able to reuse some number of addresses, recourse is usually had to a network address and port translation (NAPT) mechanism. The term “NAT” is sometimes used below for “NAPT”, even though not strictly accurate. Furthermore, various types of natting table can be used, in particular tables of the “full cone”, “port restricted” or indeed “symmetrical” types.
The conventional version of the IP address system, known as the “IPv4 system” is standardized, in particular on the basis of Internet Engineering Task Force (IETF) document request for comments (RFC) 791.
It is commonly accepted by IP service providers that it is inevitable that public IPv4 addresses will run out.
In order to limit the number of public IPv4 addresses needed for providing an IP connectivity service to a set of clients, proposals have been made and implemented by some operators for a double NAT solution, also known as an “operator NAT” solution. It consists in activating a NAT function within the operator's telecommunications network, in such a manner that the home gateways use a private address in their outward natting tables (instead of a public address). Thus, the “operator NAT” function provides a second level of translation from the private addresses of home gateways to public addresses, thereby enabling a service provider to save a non-negligible number of public IPv4 addresses needed for providing the IP connectivity service.
Nevertheless, that “operator NAT” solution presents several drawbacks, including the following:                the processing of IP data packets is made more complex: by introducing a second level of address and port translation, it is necessary for data packets to be modified twice;        the need to adapt the implementation of conventional application signaling protocols or the application level gateway (ALG), such as the domain name system (DNS), file transfer protocol (FTP), or indeed session initiation protocol (SIP); for example, with SIP, the IP address and the port that are used are specified in SIP signaling, and the corresponding SIP message needs to be modified by the SIP ALG in order to take account of the NAT; although this function can be implemented at the level of a home gateway, it is much too difficult to implement at the level of an operator NAT that federates numerous clients; in a variant, the public address and port currently in use for the terminal need to be communicated to the SIP application; and        a deterioration of the IP connectivity service offered by the operator of the public telecommunications network, in particular because functions such as “port forwarding” or DynDNS” are not easily made compatible with the “operator NAT” function.        
The document entitled “IPv4 connectivity access in the context of IPv4 address exhaustion: port range based IP architecture” available at the site http://www.ietf.org/internet-drafts/draft-boucadair-port-range-02.txt teaches another solution for delaying the exhaustion of IPv4 addresses. That solution consists in sharing a public IPv4 address between a plurality of pieces of client equipment, with the clients being distinguished from one another when routing data packets having a shared IPv4 address as their destination address, by means of respective port numbers selected from constrained ranges of port numbers, each of which is reserved for a corresponding destination piece of equipment. The data packet is initially routed to a node of the network suitable for routing packets on the basis of the destination address and of the port. The node has a correspondence table associating the pair formed by the shared address and the reserved range of port numbers with a single identifier of the destination equipment. The single identifier, e.g. private IP address, is used for routing the data packet to the destination client equipment.
A first drawback of that solution is that it requires the correspondence between the shared address and the destination equipment identifier to be stored in the node equipment, thereby making it necessary to pass via that node equipment.
Furthermore, the node equipment suitable for processing data packets is generally equipment that is dedicated to processing all of the packets destined for a shared address. The node equipment serves all of the clients in a public address zone. If the unique identifier of the destination equipment is a private IP address or a point-to-point protocol (PPP) session, that requires the node equipment to be situated in a network giving access to the telecommunications network: ISP's have only a limited number of private addresses available to them, and centralizing the node equipment would require complex mechanisms for reusing private addresses between different zones (of the virtual private network (VPN) type). A second drawback of such a solution, once it requires a large number of nodes of this type to be implemented in the telecommunications network (since the nodes must be near to the accesses), is that it involves a large amount of expense for an operator.
Finally, a third drawback of that solution is that it does not enable a data packet to be routed if it does not include the destination port number.
In any event, the above-described solutions can only put off the phenomenon of public IPv4 addresses running out, and cannot prevent it.
In order to solve this problem, the Internet community has taken steps that have led to a new protocol being defined, which is known as Internet protocol version 6 (IPv6). This new version of the IP protocol provides a large number of IPv6 addresses and a hierarchical routing mechanism with improved performance. The same providers are worried by the warnings recently issued by the IETF, in particular in reports presented to the global routing operations working group (GROW) about the risk of IPv4 addresses running out by the end of 2010.
IPv6 addresses are 16 bytes long, i.e. 128 bits, as compared with 4 bytes (32 bits) for IPv4 addresses. The potential number of addresses is thus extremely large compared with the number of IPv4 addresses. An IPv6 address has two parts:                a left part (the prefix) identifies a subnetwork of the domain; and        the right part identifies a position machine connected to the subnetwork.        
Generally, the longest prefixes allocated to a subnetwork are “/64” prefixes, i.e. they comprise 64 bits. The remaining 64 bits (on the right) of the address are then used to identify a particular machine belonging to the subnetwork. Prefixes of shorter lengths (e.g. /56 or even /48) serve to identify subnetworks of greater size, often themselves having /64 subnetworks. Nevertheless, in the IPv6 standard there is nothing to prevent prefixes being used that are longer than /64, and it is thus possible, for example, to envisage using a /116 prefix that makes it possible to identify a subnetwork capable of containing 212=4096 machines (since 128−116=12).
Document RFC 3315 describes a protocol known as the “DHCPv6” protocol that makes it possible in particular for machines situated in a subnetwork to obtain an IPv6 address from a dedicated server known as a “DHCPv6 server”.
Furthermore, concerning not a simple IPv6 machine, but rather an IPv6 router or gateway, such equipment must have one (or more) IPv6 prefixes that represent(s) the subnetwork(s) for which the equipment routes data packets.
An extension of DHCPv6 enables a router requesting one (or more) IPv6 prefix(es) to make its request from equipment that is capable of delegating prefixes (typically an upstream router). This extension is described in document RFC 3633 (entitled “IPv6 prefix options for dynamic host configuration protocol (DHCP) version 6”), which specifies an “identity association for prefix delegation option” in DHCPv6 messages for transmitting the delegated prefix(es). Once the requesting router has had one or more IPv6 prefixes delegated thereto, it routes all the IPv6 packets going to or from machines having addresses that include the prefix(es) managed thereby.
Nevertheless, the IPv6 protocol is not yet in widespread practical use by operators, for financial, strategic, and technical reasons associated with managing the complexity of transition and migration operations. The changeover to IPv6 will therefore necessarily give rise to a transition period during which IPv6 domains will need to be capable of interconnecting with IPv4 domains. Unfortunately, there is no provision in present networks for facilitating such interconnection in a manner that is effective and optimized without giving rise to additional states in the network nodes involved in providing the IP connectivity service.
That is why a so-called “DS-lite” solution to the problem of IPv4/IPv6 interconnection has been proposed in the document entitled “Dual-stack lite broadband deployments post IPv4 exhaustion” that is available on the site http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-01.txt (the term “dual stack IP” is used to designate a system suitable for managing both IPv4 addresses and IPv6 addresses). The DS-lite architecture is shown in FIG. 1.
In this architecture, terminals T such as T-A, T-B have respective private IPv4 addresses and are each connected to a customer premise equipment (CPE) gateway. Each CPE gateway is connected to a “DS-lite” node situated at the interface between the IPv6 network and at least one IPv4 network. The CPE gateways and the DS-lite nodes have IPv6 addresses.
A terminal T sends IPv4 packets to the CPE gateway, which packets have the terminal's private IPv4 address as the source address and the other party's public IPv4 address as the destination address. A terminal T receives IPv4 packets from the CPE gateway, which packets have the other party's public IPv4 address as the source address and the terminal's own private IPv4 address as the destination address.
When a CPE gateway receives an IPv4 packet from a terminal T of its local network, it encapsulates the packet in an IPv6 packet with the IPv6 address of the CPE gateway as the source address and the IPv6 address of the DS-lite node to which it is connected as the destination address. Thereafter, it routes the IPv6 packet to the DS-lite node. When a CPE gateway receives an IPv6 packet from the DS-lite node, it extracts the IPv4 packet therefrom and routes the IPv4 packet to the destination address constituted by the private address of a terminal T in its own local network.
When a DS-lite node receives an IPv6 packet from a gateway CPE-A containing an IPv4 packet having the following characteristics:                issued by a terminal T-A in the local network of the gateway CPE-A;        source address AdresPrivT-A, source port PortPrivT-A; and        destined for the public address AdresPubB of a third party B;        
then the DS-lite node:                extracts the IPv4 packet from the IPv6 packet;        changes the private source address AdresPrivT-A, putting the public address AdresPubA that it has selected for the call in the place of the IPv4 address; and        changes the source port PortPrivT-A into a source port PortPubA that is available for the address AdresPubA.These last two operations constitute the above-mentioned NAPT translation function.        
Thereafter, the DS-lite node routes the packet as a function of the public IPv4 destination address AdresPubB as follows.
If the address AdresPubB is on the IPv4 network side, then the packet is routed directly to the IPv4 network.
If the address AdresPubB belongs to the pool of public addresses belonging to the DS-lite node itself, i.e. if the destination B is managed by the same DS-lite node via a gateway CPE-B, then the node:                changes the destination address AdresPubB, putting the private address AdresPrivT-B in its place; and        changes the destination port PortPubB, putting the destination port PortPrivT-B in its place.        
Those last two operations themselves also constitute a NAPT function.
Thereafter, the DS-lite node:                encapsulates the IPv4 packet in an IPv6 packet with the IPv6 address of the DS-lite node as the source address and the IPv6 address of the gateway CPE-B as the destination address; and        routes the IPv6 packet to the gateway CPE-B.        
When a DS-lite node receives a packet coming from an IPv4 network, the following situations may arise:                if the destination network forms part of the pool of public addresses of the DS-lite node, that means that the destination of the packet is a terminal T-A of a client A processed by the DS-lite node; in which case the DS-lite node:                    changes the destination address AdresPubA, replacing it with the private address AdresPrivT-A;            changes the destination port PortPubA into PortPrivT-A (NAPT function);            encapsulates the IPv4 packet in an IPv6 packet having as its source address the IPv6 address of the DS-lite node and as its destination address the IPv6 address of the gateway CPE-A; and            routes the IPv6 packet to the gateway CPE-A;                        otherwise the packet is rejected or routed directly in IPv4.        
The above “DS-lite” solution presents the drawback of requiring frequent applications of the NAPT function; it should be understood that these applications are complex.
A variant of the DS-lite solution, known as “DS-lite-interco” is proposed in the document entitled “Deploying dual-stack lite in IPv6-only network” that is available at the site http://www.ietf.org/id/draft-boucadair-dslite-interco-v4v6-02.txt. That solution modifies the “DS-lite” solution described briefly above by separating the NAPT functions from the IPv4/IPv6 interconnection functions, thereby enabling IPv4 traffic encapsulated in IPv6 to be transferred directly between “DS-lite” nodes.
The “DS-lite-interco” architecture is shown in FIG. 2. This architecture has DS-lite nodes situated in an IPv6 network and performing the NAT or NAPT function of changing IPv4 address and port, where appropriate. Furthermore, each DS-lite node is capable of routing IPv6 packets to a “DS-lite-IX” node situated at the interface between the IPv6 network and at least one IPv4 network, where it performs solely the IPv4/IPv6 interconnection function.
Furthermore, the “DS-lite-interco” solution uses IPv6 addresses that are constructed by combining an IPv6 prefix with a public IPv4 address: an address as constructed in this way is referred to below by the terms “public IPv6/IPv4 address”. As shown in FIG. 3, this combination may be a mere concatenation. The IPv6 prefix may be a unique prefix (referred to below as “PrefU”) such as a prefix defined by the Internet Assigned Numbers Authority (IANA), or a prefix that is specific to a given IPv6 network (e.g. characterizing an ISP).
The operation of the terminals and of the CPE gateways remains unchanged from the operation described briefly above for the DS-lite architecture. In contrast, the DS-lite node and the DS-lite-IX node exchange routing information between one another relating to the IPv4 addresses that belong to them or for which they hold public IPv6/IPv4 addresses.
When a DS-lite node receives an IPv4 packet encapsulated in an IPv6 packet from a gateway CPE-A, it extracts the IPv4 packets therefrom, translates the private IPv4 source address and port into a public IPv4 address and port (NAPT function), and maintains the correspondence between the public and private IPv4 and IPv6 addresses and ports (AdresPrivT-A, PortPrivT-A, AdresPubA, PortPubA, IPv6 address of gateway CPE-A), exactly as in the DS-lite method.
Thereafter, the DS-lite node routes the packet as a function of a public IPv4 destination address AdresPubB as follows:                if the DS-lite node possesses a public IPv6/IPv4 route (PrefU|AdresPubB) for this address AdresPubB, it encapsulates the IPv4 packet in an IPv6 packet with the public IPv6/IPv4 address (PrefU|source IPv4 address AdresPubA) as the source address and the public IPv6/IPv4 address (PrefU|destination IPv4 address AdresPubB) as the destination address, and it routes the packet to the DS-lite node or DS-lite-IX node concerned;        if the address AdresPubB belongs to a pool of public addresses of the DS-lite node, operation is the same as in the DS-lite method: the DS-lite node translates the address AdresPubB into the corresponding private IPv4 address and port (NAPT function), encapsulates the IPv4 packet in an IPv6 packet with the IPv6 address of the DS-lite node as the source address and the IPv6 address of the corresponding gateway CPE-B as the destination address. Thereafter, it routes the packet to the gateway in question CPE-B;        otherwise the packet is rejected.        
When a DS-lite node receives an IPv6 packet from another DS-lite node or DS-lite IX node, it routes the packet as a function of the public IPv4 destination address AdresPubB a follows:                if the address belongs to the pool of public addresses of the DS-lite node, the operation is the same as in the DS-lite method: the DS-lite node extracts the IPv4 packet, translates the address into the corresponding private IPv4 address and port (NAPT function), encapsulates the IPv4 packet in an IPv6 packet and gives the packet the IPv6 address of the DS-lite node as the source address and the IPv6 address of the corresponding CPE gateway as the destination address. Thereafter, it routes the IPv6 packet to the CPE gateway in question;        if the address corresponds to an IPv6 address of another DS-lite node or DS-lite-IX node, the IPv6 packet is routed directly to the DS-lite or DS-lite-IX node in question;        otherwise the packet is rejected.        
When a DS-lite-IX node receives an IPv6 packet from a DS-lite or another DS-lite-IX node, it routes it as a function of the public IPv4 destination address as follows:                if the address is on the IPv4 network side, the DS-lite-IX node extracts the IPv4 packet and routes it directly to the IPv4 network;        if the address corresponds to an IPv6 address of a DS-lite node or another DS-lite-IX node, the IPv6 packet is routed directly to the DS-lite node or to the DS-lite-IX node in question;        otherwise the packet is rejected.        
When a DS-lite-IX node receives a packet from the IPv4 network, it routes it as a function of the public IPv4 destination address as follows:                if the address corresponds to an IPv6 address of a DS-lite node or another DS-lite-IX node, the IPv4 packet is encapsulated in an IPv6 packet with the public IPv6/IPv4 address (PrefU|source IPv4 public address) as the source address and the public IPv6/IPv4 address (PrefU|destination IPv4 public address) as the destination address, and then it routes this IPv6 packet to the DS-lite node or the DS-lite-IX node in question;        otherwise the packet is rejected or routed directly in IPv4.        
Thus, the “DS-lite-interco” solution simplifies packet routing compared with the “DS-lite” solution, but applications of the NAT/NAPT function in the network remain just as frequent, in particular when a terminal T-A is situated in the private network associated with a gateway CPE-A (itself connected to a node DS-lite-A) communicates with a terminal T-B situated in the private network associated with a gateway CPE-B (itself connected to a node DS-lite-B), since under such circumstances both DS-lite devices implement an expensive application of the NAT/NAPT function.